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protocols, as well — but in a topsy-turvy 
way. When telecom-heads confront IP 
transport, the basic old telecom model 
(•drive dumb endpoints with contetiSrii- 
ed, vertically-integrated intelligence") 
gets turned sideways. More intelligence 
is concentrated at the endpoints — both 
to manage what's assumed to be an ex- 
tremely-fallible network, and to handle 
facilities negotiations between more- and 
less-complex devices, all residing some- 
where on the (presumed) vertical contin- 
uum from voice, to video, to data, to all- 
of-the-above. But this distribution of 
intelligence to endpoints doesn't make 
things simpler at the network core. 

H.323 — derived from the wireline 
videoconferencing protocol, H.320 — is 
an obvious case in point complex, deter- 
ministic, vertical. Hie protocol — spread 
across at least six major documents (not 
counting optional addenda and semi-offi- 
cial commentary) — defines every com- 
ponent of a voice/video/data conferenc- 
ing network: terminals, gateways, 
gatekeepers, MCUs, and other feature 
servers. H.323 uses ISDN-style Q.931 sig- 
naling for call setup, plus other protocols 
— RAS and H.245 — for terminal/gate- 
keeper negotiations and codec/facilities 
handshaking. All these protocols — 
dozens of back-and-forth messages — 
must be managed to set up a simple, 
point to point voice call. 

H.323 is a fairly-stable standard — you 
can go to a range of third parties and buy 
stack components for host deployment or 
terminal implementations. Interoperability 
tests are proceeding. Scaleability concerns 
are being addressed. H.323 gateway net- 
works are deployed. H.323 PC clients are 
widely available — NetMeeting, for one, rep- 
resenting a kind of low-end, de-facto stan- 
dard for client-side functionality. The first 
relatively low-cost H.323 telephones are in 
the pipeline for second-quarter appearance. 
There's no question that H.323 works. 

But anyone who looks at the standard 
should have questions. The New Network 
isn't going to be nearly as fallible as H.323 
presupposes. (Nor is H.323 especially ro- 
bust — the numerous messages required 




to set up calls mean plenty of targets for 
line-hits. Call setup failure due to packet 
loss is one of the things CT Labs measures, 
when they test H.323 gateways — perfor- 
mance of some systems is truly dismal.) 
There's going to be plenty of bandwidth — 
the idea mat IP telephony is going to hap- 
pen across 4.8 kbps compressed connec- 
tions is pretty-well outmoded, as is the idea 
mat most IP connections wiH riave to nego- 
tiate bandwidth shirrs, mid-call. Do we re- 
ally need a facilities-negotiation sub-proto- 
col (H.245) that B°t only manages mid-call 
codec changes, but is actually capable of 
(hold on to your hat) rhanging H.245 revi- 
sion-levels, on the fry? And why would any- 
one want to vise. ISDN-style signaling to set 
up calls across an IP network? 

Yes, H.323 works. But there's some- 
thing fundamentally wrong-headed about 
it Ifs all about concentration and control 
— dynamics diametrically opposed to the 
simple, open, horizontal, multi-purpose 
philosophy of pure Internet technologies 
like e-mail and the web. 

This determinism — in combination 
with other "legacy" tendencies influenc- 
ing the development of IP telephony net- 
works and CPE — entails a fundamental 
risk to the converging communications 
economy. The IP telephony revolution 
could hang fire — or actually fail — if 
persistent legacy characteristics obscure 
real "killer app" opportunities, or hamper 
IP telephony's ability to elide with the 



Net* s most powerful technologies. 

IS THERE A BETTER WAY? 

SIP — me session interface protocol — may 
offer a better way to do telephony in an IP 
environment SIP comes at the challenge of 
converged communications from a horizon- 
tal. Net-head perspective. The result is a sim- 
ple protocol with profound implications. 

Like the web — originally designed as a 
document-sharing system for arariVrmfs — 
SIP originated with a simple, practical brie£ 
In the nnd-90's, Henning Schuhrinne — 
now associate Professor m the Departments 
of Computer Science and Electrical Engi- 
neering at New York's Columbia University; 
Jonathan Rosenberg — now Chief Scientist 
atSIPsoirwaremakerdynarmcso^ 
end others began work on a signaling proto- 
col that defines call setup and teardown 
functions as simple text commands. IP tele- 
phony — as we conceive it today — wasn't 
yet on their radar-screen. 

"At that stage," Professor Schiilzrinne 
remarks, "IP telephony as a term probably 
didn't even exist, at least not in my com- 
munity. Initially, SIP was intended to cre- 
ate a mechanism for inviting people to 
large-scale, multipoint conferences. After a 
short while, it became clear mat technol- 
ogy-wise, it was not a significant jump 
from where we were to setting up point-to- 
point conferences — essentially 'phone 
calls.* And once 'IP telephony* becattie \ht 
thing to do, then prople started looking pri- 
marily at using the protocol for voice appli- 
cations. But the emphasis of SIP has al- 
ways been to remain as independent as 
possible of the media it underlies." 

This abstractive approach is one of the 
keys to SIP's simplicity and elegance. 
Jonathan Rosenberg explains: "Ifs actual- 
ly not even just media mat SIP abstracts. 
The protocol makes a total separation be- 
tween what it means to be a session, and 
what it means to establish one. SIP talks 
about establishing or modifying or termi- 
nating a session, but that particular ses- 
sion could just a$ easily be a rnuMplaysr 
Doom game as it could be a voice channel 
or a videoconf ei ence." 

So too, die decision to format SIP mes- 
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sages as text (instead of more bandwidth- 
economical, packet-size observant theoret- 
ically 'easier to parse/ and of course, con- 
trollable binary) was a profound one * Text 
is human-readable. Text is flexible: Inter- 
preting text demands some parsing intelli- 
gence — this renders applications more ro- 
bust and lends itself to innovation. 

Most to the point text processing lies 
at the heart of the Net's true killer apps: e- 
mail and the web. Extensible tagging sys- 
tems, document identification, data-type 
declaration, parsing methods and soft- 
ware for same — all these have been 
worked over, normalized, and shared-out 
by Net-heads in the process of bringing 
the modern Net online. Sdmlzrinne and 
his colleagues understood all this, and 
made a second leap: They decided SIP 
text messages would be composed in 
standard ISO UTF-8 (ASCII Unicode) 
characters, using HTTP t.i syntax. 

A SIP message looks like the first five 



or six lines of source behind a well- 
formed web page (the part that says: 
'Content-type: etc, etc'). SIP messages 
look this way because that's what they are 
— an application of the Nef s simplest, 
most widely-implemented, most general- 
purpose system for document-type decla- 
ration. SIP also adopts the conventional 
URL format for addressing server entities 
and people: Your SIP "phone number" 
will likely be *yourname(g>yourhostcom/ 
with an optional port number (Le., the 
same as your e-mail address, though 
many variations of this basic plan are 
supported, including ways of embedding 
a standard phone number in an URL). 
The URL is translated to an IP address 
(fixed, dynamic, temporary, etc) through 
DNS, the generic nameserver system. 

"In H.333," explains Schulzrinne, 
"there is very much a vertical integration 
notion present. It specifies everything 
from the codec for the media down to how 



you carry the packets in RTP, because part 
of the specification is to describe the con- 
tent of the data stream. In the IETF [the 
standards body promoting SIP], we've tak- 
en much moxe of a Legolike approach, 
much more horizontal. What we've tried 
to provide are building blocks, which fit 
together with a number of different Inter- 
net protocols, so that we can use a com- 
mon URL for naming, we can use MIME 
for describing content, etc" 

Rosenberg emphasizes the point "We 
didn't go and define our own type of 
addresses because we saw that the 
Internet already had address formats, 
URLs, and we figured that people are 
probably going to want to throw together 
URLs of different types, as they have else- 
where on the Internet And without even 
really considering the implications of that 
decision, the service possibilities it has 
enabled have been huge. For example, 
with SIP, if s just as easy to transfer 
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someone to another phone as it is to 
transfer diem to a web page or any other 
application that accepts URLs — even 
ones like instant messaging, which didn't 
exist when we wrote the spec" 

The mechanism for doing this magic 
doesn't even belong to SIP, per se — it 
just falls out of the decision to use stan- 
dard DTDs and URLs to manage telepho- 
ny. In feet, SIP goes well beyond this 
point in cleaving to broad-based, general 
purpose standards. Its message codes, for 
example — relatively few in number — 
map to HTTP's "fkstdi^t-most-signifi- 
cant" decimal sequence. So (as any web 
programmer will appreciate) if you get a 
SIP message code somewhere in the 
400's, it means you're doing something 
wrong. A message in the 500*8 means the 
far-end server has crashed. 

When a web-oriented programmer 
looks at SIP, therefore, there's an imme- 
diate sense of the familiar. As the pro- 
grammer digs deeper, there's an even- 
more-reassuring feeling that SIP does 
what it does — register endpoints, trans- 
mute and pass on information, set up ses- 
sions on dynamically-allocated ports, and 
let endpoints negotiate protocol and 
codec details — in a minimal, practical 
way. If IP endpoint addresses are known, 
a single message exchange suffices to set 
up a point-to-point call, \nrh%A\ng real- 
time protocol and ctxiei: determination 
and dynamic port allocation on each side. 
H.323V2 can only approach such economy 
when its as-yet-unstandardized 'fastStart' 
call setup option is used. 

To support mobility and higher-order 
applications, SIP defines several "useful 
entities" (read: simple pieces of software 
that sit on a well-known port) that help 
manage calls in different ways: registrars, 
which maintain a map of "what IP address 
a giv^n user is at, righl now"; proxies, 
which can act as transcoders, auto-respon- 
ders, and forwarding agents; and redirect 
servers, which perform a subset of for- 
warding functions. These helpers can be 
set up to -work around aU the common 
prubfems of dynamic IP addressing, PC 
terminals mat get turned oft workers that 



move from place to place, as well as all 
sorts of higher-order applications. 

Again, the general scheme looks famil- 
iar to Intemet-aware programmers. SIP 

servers are. of course, complete abstrac- 
tions — corresponding in no way to "one 
box per function," except where scale and 
simplicity mandate mis solution. In many 
cases, a single box will house several — or 
all — of the discrete functionaries; just as 
a small-office server may today house a 
DHCP, a DNS, SMTP/POP3 e-mail 
servers, an HTTP server, and other ele- 
ments. As with other Net services, the seg- 
regation of SIP entities exists mostly for 
the sake of practicality. In a typical office, 
workers turn of! their PCs at the end of 
the day, but the servers keep running. A 
SIP proxy, mounted on one of the servers, 
stays up and keeps answering calls. 

The proxy is SIP's most powerful 
"chunk"; A complete proxy can redirect 
firewall, transcode, reoriginate. And it 
can house call agents — yet another 
abstraction, translating roughly to "a vir- 
tual endpoint" But even the light-duty 
functions of a proxy — equivalent to 
those of a redirect server and simple 
enough to be encapsulated even in an 
endpoint, if desired — are enormously 
powerful. For example, you can adapt an 
ACD to use a SIP proxy server as its 
"switching engine" — the proxy takes 
INVITE requests ffbtn callers, returns a 
182 'queued* message, then (when agents 
are tree), sends redirect messages to call- 
ing clients — the subsequent connections 
are made point to point 

SIP's intimate association with Net stan- 
dards and approaches — its consistent use 
of abstraction and "necessary and suffi- 
cient" simplicity — are enormously benefi- 
cial. Not only does SIP integrate with, scale 
in similar fashion to, and otherwise map it- 
self to the Net's most important drivers, but 
it also establishes telephony as part of a con- 
tinuum of Net media options — readily ac- 
cessible to Net programmers, and eventu- 
ally (through -widespread use of SI PCPL — 
call processing language — and other tools 
now in the pipeline) to rank-and-file web- 
monkeys, as well 



WHY SIP MAY WIN 

Perhaps the most powerful aspect of SIP is 
again an abstraction. Unlike H.323, which 
specifies everything but the color of the 
knobs and dials, SIP doesn't specify any- 
thing it doesn't have to. It's just a simple 
toolkit, atop which smart clients and appli- 
cations can be built Ultimately, it means 
freedom for the enterprise, carriers — the 
whole telecom ecology. It means enormous 
variation in how services are deployed, and 
in what telephony looks like. 

For example, SIP is central to several 
carriers' plans to deploy IP Centrex in 
tandem with basic Net access, e-mail, 
domain hosting, DNS, firewall, and other 
'business package' services. Plug a hard- 
ware SIP phone into a LAN outlet input 
your e-mail address and you're done: The 
phone grabs an IP address from a local 
DHCP, sends a multicast registration 
request to the carrier's registrar, and is 
ready to make and take calls. Once infor- 
mation about colleagues (e.g., their IP 
addresses) is absorbed by the client, it 
requires no help from carrier servers to 
perform most of the functions of a PBX: 
i.e., it can "extension dial" point to point, 
put callers on hold; transfer (just send a 
redirect and have the caller's client re- 
originate), etc. Outbound (i.e., outside the 
enterprise) calls bounce off the carrier's 
DNS, then out into the cloud (or carrier- 
maintained gateways). Inbound calls 
(coming across the Net or through gate- 
ways) hit the carrier's proxy momentarily, 
and get redirected to endpoints. Unless 
the carrier wants to host messaging, con- 
ference bridging, ACD, or other sophisti- 
cated services (and many will) basic fea- 
ture service (except for that annoying 
gateway maintenance) becomes a "no 
overhead* proposition. 

By the same token, some may choose to 
house SIP-server and application smarts 
on-premise — much as today, firms with 
serious e-commerce ambitions may elect to 
babysit a rack of web servers. Ultimately, 
however, this may end up being more a 
matter of taste than necessity — it's hard to 
imagine a SIP app that -would mandate in- 
stalling CPE. In fact, we expect SIP to be a 
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major enabler in the global drive to elimi- 
nate or minimize telephony premise 
equipment. If baby-sitting racks of SIP 
servers is an issue for anyone, if s going to 
be third-party ASPs — who'll spring up to 
OEM-host SIP services to carriers, or rent 
them directly to customers. 

The market for SIP-enabled services 
will be rich. And — so Schulzrinne, 
Rosenberg and others predict — it will 
comprise both classically mass-market 
and true vertical-market applications, just 
like the web does, today. Vertical apps 
will emerge — somewhat ironically — as 
the result of SIP's horizontal orientation. 

"I mink, fundamentally, the success of 
the Internet is all about taking vertical 
pieces and breaking them into horizontal 
components," says Rosenberg. "The rea- 
son why the Internet succeeded in a lot of 
cases, where BBSs and other online ser- 
vices had failed, is because the Internet im- 
mediately separated out transport from ser- 
vices, while the others tried to integrate 
access, transport, and services.* 

"Now we're starring to see Internet tele- 
phony following a similar evolution — 
we've already broken up the telephony 
gateway, for example, into a Softswitch and 
a media gateway. But at this point if s still 
a vertically integrated market For the evo- 
lution to continue, we're going to have to 
break up the model into even more pieces, 
so that one user's services can reside in any 
number of different places in the network, 
depending on what they are." 

On the Internet this idea is a given. "An 
ISP doesn't build or own all the web services 
its users access. It lets other people build 
web services mat are customized for a par- 
ticular group of people, because thafs some 
other person's expertise* Rosenberg adds. 
For telecom, however, this proposition in- 
volves some major paradigm shifting. 

"There used to be a kind of black art,* 
Schulzrinne quips, "where you had to un- 
dergo rituals and have your head shaved 
appropriately before you were allowed to 
program an SS7 service. If s not something 
you could just learn in school. But what 
we're doing is making it possible for people 
who have a vunilar skill set to web page de- 



signers, who know some standard script- 
ing languages, to develop services that are 
either customized for their own organiza- 
tion, or target some vertical market" 

As Rosenberg points out, "The Inter- 
net is all about access to tools. It was be- 
cause some random yahoo could sit down 
and say, "Gee, this is a neat idea," and 
then whip up the service ... that there was 
so much innovation and so much growth 
in commerce, all at once. In the voice 
world, though, I'd have to wait for my tel- 
co to go through the three-year cycle of 
adding a new service, and it would still 
not be a true vertical-market service. 
We've never seen vertical-market special- 
ized voice services, never. But we've seen 
tons of vertical-market web services de- 
ployed in the past few years, and that's 
where a huge source of value has been. 
So our mission is to create a horizontal 
platform that lets anybody create vertical- 
market services incorporating voice." 

ARE WE DREAMING? 

A virtual web of decentralized services. 
Disparate endpoints communicating 
with one another through nothing more 
than their own embedded software. Ya- 
hoo! deploying voice applications once 
controlled by AT&T ... Are we living in a 
fantasy world? Yet every possible indica- 
tion that we've seen from the industry in 
recent months suggests that SIP, and its 
fundamental implications for communi- 
cation, are about to hit in a big way. 

Part of the proof lies in the wide range 
of products that are already incorporating 
SIP at different levels in the network. In 
terms of infrastructure, dynamicsoft is 
leading the way by providing SIP proxies 
and location services as the basis for a hor- 
izontally integrated applications platform. 
The Softswitch community has largely em- 
braced SIP as a way of communicating be- 
tween softswitches and is strongly consid- 
ering the protocol as a means for tying 
together softswitches and application 
servers. At the edges, companies like Au- 
dioTalk (now HearMe) and NetSpeak are 
basing software VoIP clients on SIP, and 
proving the technology to be tisablc today. 



for anyone with a multimedia PC and 
browser. And PingTel is taking the next 
logical step (really a leap) at the edge by 
building the first truly intelligent SIP tele- 
phones, and using a fully integrated Java 
environment that demonstrates the extent 
of the protocol's proximity to the Internet. 

Perhaps most significantly, SIP is gar- 
nering a high degree of support from carri- 
ers. Level 3 has made recent announce- 
ments that describe widespread use of SIP 
throughout its network. And, at the most re- 
cent VON show, MCI WorldCom demon- 
strated a public test network that incorpo- 
rated S I P hased products from at least seven 
different vendors, all interoperating with 
one another. 

The scope of S IP-based products and 
services is likely to grow immensely over 
the next few months and years. As it does, 
however, we expect to see the protocol less 
emphasized rather than more — just as 
one doesn't necessarily emphasize the use 
of HTTP in an Internet application. Al- 
ready, a growing group of players are ap- 
proaching it from the right direction. 
"What we've found," says Rosenberg, "is 
that all sorts of vendors and service 
providers have particular applications that 
they want to get done. When they try to fig- 
ure out how, the find they have a choice of 
protocols, none of which has already de- 
fined the necessary feature set, but which 
can serve as a platform to hm\& upon. In- 
creasingly, we're finding they want to build 
on SIP. As a result, we're seeing a lot of 
vendors defining extensions, and doing 
things that we hadn't originally conceived 
of SIP to do; but, men again, that was sort 
of the whole idea, now, wasn't it?" 

3COM 

3Com (Santa Clara, CA — 408-326-5000, 
www.3c0m.com) has come out strong in 
support of SIP, and has been active in pro- 
moting its acceptance for quite some time. 
Initial implementations have largely cen- 
tered around using SIP as a way of inter- 
facing between a Palm Pilot and a S IP- 
based telephone, which the company has 
demonstrated at trade shows in recent 
months. The Palm integration, however, 
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while holding undeniable sex appeal, as 
well as the potential for some truly useful 
applications (dialing directly out of your 
Palm address book, as a basic example), is 
really a way of directing attention toward a 
larger 3Com project — namely the devel- 
opment of an IP Centrex solution. 



Having just launched its first beta trials, 
and with general availability expected this 
summer, the product is already fairly dose 
to completion. Essentially, the system con- 
sists of a series of SPARC servers mat will 
run Centrex-like features, and communi- 
cate with client devices over IP, through a 



3Com'sSJPinmitirainc^ 

applications with fts popular, Ethernet-based NBX* 

100 phones* 

SIP server. In addition to the call control 
and applications software, 3Com has devel- 
oped the SIP server itself, as wefl as a line 
of SIP phones to reside at the customer 
premise. Nevertheless, the company plans 
to use fully open interfaces at every level, so 
that any component of the system — 
phones, servers, applications — could be 
replaced or complemented by a standards- 
based product from a third-party. This 
open architecture differs from 3Com's en- 
terprise LAN-PBX offering, the NBX-100, 
which uses a proprietary protocol over Eth- 
ernet to interface with phones. Although 
3Com eventually plans to migrate the N BX 
to an open I P protocol , they are first and 
fbxernostk>okmgatSIPasawideareapra> 
tocoi and are in mis respect in Hne wim the 
riiinlring of many other vendors. Ikhlaq 
Suhu, 3 Corn's VP of Internet communica- 
tions — network systems business unit, 
points to SIP'S inherent scalability, reHabil- 
ity/acd simplicity — all of which are re- 
lated to the fact that the protocol defines a 
peer-to-peer, "stateless" call model — as its 
main advantages for use in networks that 
extend beyond the local area. 

In addition to participating in and host- 
ing SIP bake-oflfe, 3Com Is currently in an 
IETF proposal to specify an open standard 
for service provisioning and authentication 
in SIP-based application server architectures 
Hke its own. The company has also submit- 
ted a draft to me IETF mat defines a standard 
method for passing SIP mess ag e between a 
Palm device and a phone. By standardizing 
its own de facto method for mis type of ap- 
plication, 3Com plans to enable developers 
of Palm apps, as well as vendors of other 
Palm OS products and other SIP phones to 
achieve me same type of integration. 




Enter 20 on cant, or at wwwjcowpatartalapliaflyjco^pfoduc^ 



66 /May aooo/CoroputerTili jfcowj crm 



